Efficient methods for protecting identity in authenticated transmissions

ABSTRACT

Systems and methods are provided for protecting identity in an authenticated data transmission. For example, a contactless transaction between a portable user device and an access device may be conducted without exposing the portable user device&#39;s public key in cleartext. In one embodiment, an access device may send an access device public key to a portable user device. The user device may return a blinded user device public key and encrypted user device data. The access device may determine a shared secret using the blinded user device public key and an access device private key. The access device may then decrypt the encrypted user device data using the shared secret.

CROSS-REFERENCES TO RELATED APPLICATIONS

The present application is a non-provisional application of and claimspriority to U.S. Provisional Application No. 61/926,908, filed on Jan.13, 2014 (Attorney Docket No.: 79900-897598), the entire contents ofwhich are hereby incorporated by reference for all purposes.

BACKGROUND

As contactless payment devices such as NFC-enabled mobile phones andcontactless cards continue to increase in popularity, maintaining thesecurity of payment transactions continues to be a concern. For example,in one scenario, an attacker may attempt to eavesdrop on a contactlesstransaction (e.g., by using a concealed radio receiver). Even if paymentinformation is encrypted or otherwise protected, the attacker mayattempt to determine the identity of a user conducting a transaction. Ifdetermined, the identity of the user could be used for illicit purposes.

Embodiments of the present invention address these problems and otherproblems individually and collectively.

BRIEF SUMMARY

Embodiments of the invention relate to efficient methods for protectingidentity in an authenticated data transmission. For example, acontactless transaction between a portable user device and an accessdevice may be conducted without exposing the portable user device'spublic key in cleartext.

In one embodiment, an access device public key may be received from anaccess device by a portable user device. A blinded user device publickey may be generated from a user device public key stored on theportable user device and a cryptographic nonce (e.g., a random value).Similarly, a blinded user device private key may be generated from auser device private key corresponding the user device public key and thecryptographic nonce. Next, a shared secret may be generated using theblinded user device private key and the ephemeral public key. The sharedsecret may be used derive a session key, and the session key may be usedto encrypt user device data such as a user device certificate. Theencrypted user device data and the blinded user device public key canthen be sent to the access device. The access device can re-generate theshared secret using the blinded user device public key and the accessdevice private key. The shared secret may then be used to re-generatethe session key and decrypt the encrypted user device data. Thus, theaccess device can obtain and verify the user device certificate withoutthe certificate being transmitted in cleartext.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an example of a system that may be used with embodiments ofthe invention.

FIG. 2 shows a diagram of communication between an access device and auser device in accordance with some embodiments of the invention.

FIG. 3 shows a method of securely obtaining user device data from a userdevice.

FIG. 4 shows a method of securely transmitting user device data to anaccess device.

FIG. 5 shows a data flow diagram illustrating operations performed inestablishing a shared secret in accordance with some embodiments.

FIG. 6 shows a more detailed data flow diagram illustrating operationsperformed in a data transmission method according to some embodiments.

FIG. 7 shows an optimized method of securely obtaining user device datafrom a user device.

FIG. 8 shows an optimized method of securely transmitting user devicedata to an access device.

FIG. 9 shows an example of a user device in accordance with someembodiments.

FIG. 10 shows a block diagram of an exemplary computer apparatus.

TERMS

Prior to discussing embodiments of the invention, description of someterms may be helpful in understanding embodiments of the invention.

The term “server computer” may include a powerful computer or cluster ofcomputers. For example, the server computer can be a large mainframe, aminicomputer cluster, or a group of servers functioning as a unit. Inone example, the server computer may be a database server coupled to aWeb server. The server computer may be coupled to a database and mayinclude any hardware, software, other logic, or combination of thepreceding for servicing the requests from one or more client computers.The server computer may comprise one or more computational apparatusesand may use any of a variety of computing structures, arrangements, andcompilations for servicing the requests from one or more clientcomputers.

The term “public/private key pair” may include a pair of linkedcryptographic keys generated by an entity. The public key may be usedfor public functions such as encrypting a message to send to the entityor for verifying a digital signature which was supposedly made by theentity. The private key, on the other hand may be used for privatefunctions such as decrypting a received message or applying a digitalsignature. The public key will usually be authorized by a body known asa Certification Authority (CA) which stores the public key in a databaseand distributes it to any other entity which requests it. The privatekey will typically be kept in a secure storage medium and will usuallyonly be known to the entity. However, the cryptographic systemsdescribed herein may feature key recovery mechanisms for recovering lostkeys and avoiding data loss. Public and private keys may be in anysuitable format, including those based on RSA or elliptic curvecryptography (ECC).

A “digital signature” may refer to the result of applying an algorithmbased on a public/private key pair, which allows a signing party tomanifest, and a verifying party to verify, the authenticity andintegrity of a document. The signing party acts by means of the privatekey and the verifying party acts by means of the public key. Thisprocess certifies the authenticity of the sender, the integrity of thesigned document and the so-called principle of nonrepudiation, whichdoes not allow disowning what has been signed. A certificate or otherdata that includes a digital signature by a signing party is said to be“signed” by the signing party.

A “certificate” or “digital certificate” may include an electronicdocument or data file that uses a digital signature to bind a public keywith data associated with an identity. The certificate may include oneor more data fields, such as the legal name of the identity, a serialnumber of the certificate, a valid-from and valid-to date for thecertificate, certificate-related permissions, etc. A certificate maycontain a “valid-from” date indicating the first date the certificate isvalid, and a “valid-to” date indicating the last date the certificate isvalid. A certificate may also contain a hash of the data in thecertificate including the data fields. Unless otherwise noted, eachcertificate is signed by a certificate authority.

A “certificate authority” (CA) may include one or more server computersoperatively coupled to issue certificates to entities. The CA may proveits identity using a CA certificate, which includes the CA's public key.The CA certificate may be signed by another CA's private key, or may besigned by the same CA's private key. The latter is known as aself-signed certificate. The CA may maintain a database of allcertificates issued by the CA, and may also maintain a list of revokedcertificates.

In a typical process, the certificate authority receives an unsignedcertificate from an entity whose identity is known. The unsignedcertificate includes a public key, one or more data fields, and a hashof the data in the certificate. The CA signs the certificate with aprivate key corresponding to the public key included on the CAcertificate. The CA may then store the signed certificate in a database,and issue the signed certificate to the entity.

A “cryptographic nonce” may include any number, string, bit sequence, orother data value intended to be used in association with a singlecommunication session. In some cases, a cryptographic nonce may berandomly or pseudo-randomly generated. Typically, a cryptographic nonceis of sufficient length as to make insignificant the likelihood ofindependently generating the same nonce value multiple times.

A “blinded key,” such as a “blinded public key” may include a key thathas been obfuscated or otherwise modified from its original value bycombination with another data element, such as a cryptographic nonce.For example, in elliptic curve cryptography, a public key may bemultiplied by the nonce to generate a “blinded public key.” Similarly, aprivate key may be multiplied by the nonce to generate a “blindedprivate key.”

An “ephemeral key pair” may include a public key (i.e., an “ephemeralpublic key”) and a private key (i.e., an “ephemeral private key)generated for use with a single transaction or other communicationsession. The ephemeral key pair may be of any suitable format, such asECC or RSA. Typically, an ephemeral key pair may is deleted once thetransaction or communication session has concluded.

An “encryption key” may include any data value or other informationsuitable to cryptographically encrypt data. A “decryption key” mayinclude any data value or other information suitable to decryptencrypted data. In some cases, the same key used to encrypt data may beoperable to decrypt the data. Such a key may be known as a symmetricencryption key.

The term “user device data” may include any data or informationassociated with a user device. Examples of user device data may includea name of a user associated with the user device, an organizationassociated with the user device, payment information such as a primaryaccount number (PAN) associated with the user device, an expiration dateof the user device, a certificate associated with the user device, etc.

DETAILED DESCRIPTION

Embodiments of the invention relate to efficient methods for protectingidentity in an authenticated data transmission. For example, acontactless transaction between a portable user device and an accessdevice may be conducted without exposing the portable user device'spublic key in cleartext.

In one embodiment, an access device public key may be received from anaccess device by a portable user device. A blinded user device publickey may be generated from a user device public key stored on theportable user device and a cryptographic nonce (e.g., a random value).Similarly, a blinded user device private key may be generated from auser device private key corresponding the user device public key and thecryptographic nonce. Next, a shared secret may be generated using theblinded user device private key and the ephemeral public key. The sharedsecret may be used derive a session key, and the session key may be usedto encrypt user device data such as a user device certificate. Theencrypted user device data and the blinded user device public key canthen be sent to the access device. The access device can re-generate theshared secret using the blinded user device public key and the accessdevice private key. The shared secret may then be used to re-generatethe session key and decrypt the encrypted user device data. Thus, theaccess device can obtain and verify the user device certificate withoutthe certificate being transmitted in cleartext.

Embodiments can protect the identity of a portable user device or otherentity in a secure communication. In some cases, an attacker may snoopor otherwise monitor data communicated between an access device and aportable user device. Since embodiments of the invention can avoidtransmitting any identifiable information (such as a user device'spublic key) in cleartext, the identity of the portable user device isprotected from unauthorized entities.

Embodiments can also achieve authenticated communication using only asingle request and a single response. This allows fast authenticationwith reduced latency, and allows the integration of the securityproperties of embodiments into other existing request/response flows,without additional requests. For example, in some embodiments, thedisclosed protocol data can be appended to the existingrequest/response.

Furthermore, embodiments can provide faster and more efficientcommunication in the case of a portable user device and access devicethat have previously communicated. In some embodiments, a registry at aportable user device may be used to store future shared secret andfuture blinded public key values for one or more access devices. Ananalogous registry at an access device can be used to store futureshared secret and future user device identifier values for one or moreuser devices. Thus, if a user device and an access device communicatemultiple times, the stored data may be used. This can avoid certainoperations, such as the elliptic-curve Diffie-Hellman (ECDH) algorithm,that may be relatively time and power intensive. This can also provideusers of contactless devices an improved experience, since a portableuser device and access device may not need to be held together for aslong. For example, in accordance with some embodiments, secure andprivate communication between two devices can be conducted in less than50 ms.

Embodiments can also appear identical to systems that do not use blindedkeys to eavesdroppers, since an eavesdropper would not know whether apublic key transmitted from a portable user device to an access deviceor vice-versa was a blinded or an non-blinded public key. Thus,embodiments can provide protection against reverse engineering of theprotocol.

I. Systems

FIG. 1 shows a system according to an embodiment of the invention. Thesystem comprises a user (not shown) who may operate a portable userdevice 101. The user may use portable user device 101 to conduct paymenttransactions in communication with an access device 102. As used herein,a “portable user device” may include a mobile phone, tablet, creditcard, debit card, or any other suitable device. As used herein, an“access device” may include any computing device suitable to communicatewith a portable user device. In some embodiments, access device 102 maydirectly communicate with portable user device 101. In otherembodiments, access device 102 may communicate to portable user device101 via an interface device, such as a smart watch, smart glasses, orany other suitable device. Access device 102 may be connected tomerchant computer 103, which may be connected to acquirer computer 104.Acquirer computer 104 may be connected to issuer computer 106 viapayment processing network 105.

As used herein, an “issuer” may typically refer to a business entity(e.g., a bank) that maintains financial accounts for a user and oftenissues a portable user device 101 such as a credit or debit card to theuser. A “merchant” is typically an entity that engages in transactionsand can sell goods or services. An “acquirer” is typically a businessentity (e.g., a commercial bank) that has a business relationship with aparticular merchant or other entity. Some entities can perform bothissuer and acquirer functions. Some embodiments may encompass suchsingle entity issuer-acquirers. Each of the entities may comprise one ormore computer apparatuses (e.g., merchant computer 103, acquirercomputer 104, payment processing network 105, and issuer computer 106)to enable communications, or to perform one or more of the functionsdescribed herein.

The payment processing network 105 may include data processingsubsystems, networks, and operations used to support and delivercertificate authority services, authorization services, exception fileservices, transaction scoring services, and clearing and settlementservices. An exemplary payment processing network may include VisaNet™.Payment processing networks such as VisaNet™ are able to process creditcard transactions, debit card transactions, and other types ofcommercial transactions. VisaNet™, in particular, includes a VIP system(Visa Integrated Payments system) which processes authorization requestsand a Base II system which performs clearing and settlement services.

The payment processing network 105 may include one or more servercomputers. A server computer is typically a powerful computer or clusterof computers. For example, the server computer can be a large mainframe,a minicomputer cluster, or a group of servers functioning as a unit. Inone example, the server computer may be a database server coupled to aWeb server. The payment processing network 105 may use any suitablewired or wireless network, including the Internet.

In some payment transactions, the user purchases a good or service at amerchant using a portable user device 101. The user's portable userdevice 101 can interact with an access device 102 at a merchantassociated with merchant computer 103. For example, the user may tap theportable user device 101 against an NFC reader in the access device 103.Alternatively, the user may indicate payment details to the merchantover a computer network, such as in an online transaction.

An authorization request message for a transaction may be generated byaccess device 102 or merchant computer 103 and then forwarded to theacquirer computer 104. After receiving the authorization requestmessage, the authorization request message is then sent to the paymentprocessing network 105. The payment processing network 105 then forwardsthe authorization request message to the corresponding issuer computer106 associated with an issuer associated with the portable user device101.

An “authorization request message” may be an electronic message that issent to a payment processing network and/or an issuer of a payment cardto request authorization for a transaction. An authorization requestmessage according to some embodiments may comply with ISO 8583, which isa standard for systems that exchange electronic transaction informationassociated with a payment made by a user using a payment device orpayment account. The authorization request message may include an issueraccount identifier that may be associated with a payment device orpayment account. An authorization request message may also compriseadditional data elements corresponding to “identification information”including, by way of example only: a service code, a CVV (cardverification value), a dCVV (dynamic card verification value), anexpiration date, etc. An authorization request message may also comprise“transaction information,” such as any information associated with acurrent transaction, such as the transaction amount, merchantidentifier, merchant location, etc., as well as any other informationthat may be utilized in determining whether to identify and/or authorizea transaction. The authorization request message may also include otherinformation such as information that identifies the access device thatgenerated the authorization request message, information about thelocation of the access device, etc.

After the issuer computer 106 receives the authorization requestmessage, the issuer computer 106 sends an authorization response messageback to the payment processing network 105 to indicate whether thecurrent transaction is authorized (or not authorized). The paymentprocessing network 105 then forwards the authorization response messageback to the acquirer computer 104. In some embodiments, paymentprocessing network 105 may decline the transaction even if issuercomputer 106 has authorized the transaction, for example depending on avalue of the fraud risk score. The acquirer computer 104 then sends theresponse message back to the merchant computer 103.

An “authorization response message” may be an electronic message replyto an authorization request message generated by an issuing financialinstitution 106 or a payment processing network 105. The authorizationresponse message may include, by way of example only, one or more of thefollowing status indicators: Approval—transaction was approved;Decline—transaction was not approved; or Call Center—response pendingmore information, merchant must call the toll-free authorization phonenumber. The authorization response message may also include anauthorization code, which may be a code that a credit card issuing bankreturns in response to an authorization request message in an electronicmessage (either directly or through the payment processing network 105)to the merchant computer 103 that indicates approval of the transaction.The code may serve as proof of authorization. As noted above, in someembodiments, a payment processing network 105 may generate or forwardthe authorization response message to the merchant.

After the merchant computer 103 receives the authorization responsemessage, the merchant computer 103 may then provide the authorizationresponse message for the user. The response message may be displayed bythe access device 102, or may be printed out on a physical receipt.Alternately, if the transaction is an online transaction, the merchantmay provide a web page or other indication of the authorization responsemessage as a virtual receipt. The receipts may include transaction datafor the transaction.

At the end of the day, a normal clearing and settlement process can beconducted by the payment processing network 105. A clearing process is aprocess of exchanging financial details between an acquirer and anissuer to facilitate posting to a customer's payment account andreconciliation of the user's settlement position.

II. Authenticated Communication Methods

FIG. 2 shows a diagram of communication between a portable user device101 and an access device 102 in accordance with some embodiments of theinvention. In some embodiments, the interaction shown in FIG. 2 may takeplace as part of a payment transaction. For example, if portable userdevice 101 is a contactless chip card, a user may tap or swipe the chipcard against an access device 102 operated by a merchant.

At step 201, access device 102 generates an ephemeral public/private keypair. The public/private key pair may be generated in any suitablemanner, such as through the use of a random or pseudo-random numbergenerator. In addition, the key pair may be generated in any suitablekey format, such as RSA or elliptic curve cryptography (ECC). In someembodiments, the ephemeral key pair may be generated before portableuser device 101 enters the contactless field of access device 102.

At step 202, access device 102 waits for some period of time aftergenerating the ephemeral key pair for a portable user device 101 toenter the contactless field of access device 102.

At step 203, once portable user device 101 enters the contactless fieldof access device 102, access device 102 transmits to portable userdevice 101 the ephemeral public key of the key pair generated at step201.

At step 204(a), portable user device 101 uses the received ephemeralpublic key to establish a shared secret with access device 101. Portableuser device 101 then uses the shared secret to derive a session key, anduses the session key to encrypt response data. In some embodiments, theshared secret may be determined by combining the received ephemeralpublic key with a user device private key and a cryptographic nonce.

At step 204(b), access device 102 waits for a response from portableuser device 101.

At step 205, portable user device 101 sends a response message to accessdevice 101. The response message may include the encrypted response dataand other data. For example, in some embodiments, the response messagemay include a blinded user device public key that access device 102 canuse to determine the same shared secret established by user device 101in step 204(a). In some embodiments, the encrypted response data mayinclude payment information such as a primary account number (PAN), anaccount expiration date, etc. In some embodiments, the paymentinformation may be included as part of a user device certificate.

At step 206, access device 102 establishes the same shared secretestablished by portable user device 101 at step 204(a). Access device102 then generates a session key using the shared secret, and uses thesession key to decrypt the encrypted response data. The decryptedresponse data can be used by access device 102 to authenticate portableuser device 101. For example, in embodiments wherein the response dataincludes a user device certificate, the certificate's signature can beverified using a digital signature algorithm.

At steps 207-210, in some embodiments, access device 102 and portableuser device 101 may exchange commands and responses. For example, accessdevice 101 may request additional data from portable user device 101, orportable user device 101 may request transaction information from accessdevice 102. Typically, the commands and responses may be encrypted usinga session key derived from the shared secret previously establishedbetween portable user device 101 and access device 102. In addition, itshould be noted that although four messages 207-210 are shown in FIG. 2,any number of messages may be exchanged between devices 101 and 102.

At step 211, access device 102 authorizes a transaction using theresponse data provided by portable user device 101. For example, in someembodiments, access device 101 may generate an authorization requestmessage as described with reference to FIG. 1, and include in theauthorization request message payment information associated withportable user device 101. Typically, portable user device 101 may leavethe contactless field of access device 101 before the transaction isauthorized. In some embodiments, once an authorization response messageis received, access device 101 can provide an indication to the user ofwhether the transaction was authorized.

Although FIG. 2 describes an example of communication between portableuser device 101 and access device 102, embodiments are not limited tothe above description. For example, some embodiments may skip commandand response steps 207-210. In some such embodiments, portable userdevice 101 may leave the contactless field of access device 101 afterstep 205.

Alternatively, in some embodiments, access device 102 may authorize thetransaction after a response message is received at step 205, but priorto sending one or more messages to portable user device 101. Forexample, in one embodiment, an account balance stored on portable userdevice 101 may be updated after access device 102 determines that thetransaction has been authorized by the issuer of portable user device101.

A. Access Device

FIG. 3 shows a method 300 of securely obtaining user device data. Insome embodiments, method 300 may be performed in conjunction with method400 of FIG. 4, wherein the method 300 is performed by an access device102, and method of 400 is performed by a user device 101.

In some embodiments, method 300 may take place as part of a paymenttransaction. For example, if user device 101 is a contactless chip card,a user may tap or swipe the chip card against an access device 102operated by a merchant.

Typically, before the method, portable user device 101 may generate orbe loaded with a user device key pair. A “user device key pair” mayinclude a public key (i.e., a “user device public key”) and a privatekey (i.e., a “user device private key”). User device 101 may alsocomprise a “user device certificate” including the user device publickey. The user device certificate may be signed by a certificateauthority, such as payment processing network 105 or issuer computer106.

At step 301, an ephemeral key pair is generated. An “ephemeral key pair”may include a public key (i.e., an “ephemeral public key”) and a privatekey (i.e., an “ephemeral private key) generated for use with a singletransaction or other communication session. The ephemeral key pair maybe of any suitable format, such as ECC or RSA. Typically, the ephemeralkey pair may be deleted once a communication session between the accessdevice 102 and the portable user device 101 has ended.

At step 302, an authentication request is sent to portable user device101 including the ephemeral public key. In some embodiments, theauthentication request can also include an access device identifierassociated with access device 102. An “access device identifier” mayinclude any data suitable to identify an access device. For example, anaccess device identifier may be a serial number, globally uniqueidentifier (GUID), network address, or any other suitable identifier. Insome embodiments, the authentication request may be sent when accessdevice 102 detects a portable user device 101, such as if it passesclose to a contactless transceiver.

At step 303, encrypted user device data and a blinded user device publickey are received from portable user device 101. A “blinded user devicepublic key” may be generated from a user device public key. For example,the blinded user device public key may be a combination of the userdevice public key and a cryptographic nonce. The “encrypted user devicedata” may include any data or information associated with a user device.For example, in some embodiments, the encrypted user device data mayinclude an encrypted user device certificate and the cryptographic nonceused to generate the blinded user device public key.

At step 304, a shared secret is generated using the ephemeral privatekey generated at step 301 and the blinded user device public keyreceived at step 303. The shared secret may be generated using anysuitable method. For example, in embodiments using elliptic curvecryptography, the shared secret may be determined using theelliptic-curve Diffie-Hellman protocol (ECDH).

At step 305, a session key is generated using the shared secretgenerated at step 304. The session key may be of any suitable format(e.g., AES, DES, Blowfish, etc.), of any suitable length, and generatedusing any suitable key derivation function. For example, in oneembodiment, the session key may be generated using the Password-BasedKey Derivation Function 2 (PBKDF2) algorithm. In some embodiments, otherdata, such as an access device identifier, may be used as additionalinputs to the key derivation function.

At step 306, the encrypted user device data is decrypted using thesession key to determine a user device certificate. The user devicecertificate may include any digital certificate that attests theidentity of user device 101. In some embodiments, the user devicecertificate may include information relating to user device 101 and/or auser associated with user device 101, such as the public key of the userdevice key pair stored on the user device, the user's name, a primaryaccount number (PAN) associated with user device 101, the account'sexpiration date, etc. The user device certificate may be signed by acertificate authority (CA). In some cases, the decrypted user devicedata may also include a cryptographic nonce used to generate the blindeduser device public key.

At step 307, the user device certificate and blinded user device publickey are validated.

Validating the user device certificate may include ensuring that thesignature of the user device certificate matches an expect value basedon a known CA public key. For example, in some embodiments, a digitalsignature algorithm, such as the elliptic curve digital signaturealgorithm (ECDSA) may be used to validate the user device certificate.

Validating the blinded user device public key may include ensuring thatthe blinded user device public key matches an expected value. Forexample, in some cases, a second blinded user device public key may begenerated using the user device public key included on the user devicecertificate, and the cryptographic nonce decrypted at step 306. Thesecond blinded user device public key may then be compared to theblinded user device public key received at step 303 to ensure that thekeys match. Alternatively, in some cases, the blinded user device publickey received at step 303 may be validated by comparing it to a storedblinded user device public key.

At step 308, if the user device certificate and blinded user devicepublic key are validated, a transaction is conducted using the userdevice data. For example, in some embodiments, an authorization requestmessage may be generated as described with reference to FIG. 1. In someembodiments, once an authorization response message is received, anindication can be provided to the user of whether the transaction wassuccessful.

It should be noted that although the method of FIG. 3 is described withreference to an ephemeral key pair, embodiments are not limited to theuse of ephemeral keys. For example, in some embodiments, access device102 may maintain a persistent key pair (i.e., an “access devicepublic/private key pair”), and use the access device public and privatekeys in place of the ephemeral public and private keys, respectively.

B. User Device

FIG. 4 shows a method 400 of securely transmitting user device data toan access device 102 from the perspective of a user device 101. In someembodiments, method 300 of FIG. 3 may be performed in conjunction withmethod 400, wherein method 300 is performed by an access device 102, andmethod 400 is performed by a user device 101.

In some embodiments, method 400 may take place as part of a paymenttransaction. For example, if user device 101 is a contactless chip card,a user may tap or swipe the chip card against an access device 102operated by a merchant.

Typically, before the method, portable user device 101 may generate orbe loaded with a user device key pair. A “user device key pair” mayinclude a public key (i.e., a “user device public key”) and a privatekey (i.e., a “user device private key”). User device 102 may alsocomprise a “user device certificate” including the user device publickey. The user device certificate may be signed by a certificateauthority, such as payment processing network 105 or issuer computer106.

At step 401, an authentication request is received comprising anephemeral public key. The ephemeral public key may be of any suitableformat, such as ECC or RSA. Typically, the ephemeral public key may bedeleted once a communication session between the access device 102 andthe portable user device 101 has ended.

At step 402, a cryptographic nonce is generated. The cryptographic noncemay be a random or pseudo-random data value generated using any suitablemethod.

At step 403, a blinded user device private key is generated using theuser device private key and the cryptographic nonce. For example, insome embodiments, the blinded user device private key may be generatedby multiplying the user device private key with the cryptographic nonce.

At step 404, a blinded user device public key is generated using theuser device public key and the cryptographic nonce. For example, in someembodiments, the blinded user device public key may be generated bymultiplying the user device public key with the cryptographic nonce.

At step 405, a shared secret is generated using the blinded user deviceprivate key generated at step 403 and the ephemeral public key receivedat step 401. The shared secret may be generated using any suitablemethod. For example, in embodiments using elliptic curve cryptography,the shared secret may be determined using the elliptic-curveDiffie-Hellman protocol (ECDH). Typically, the method used to generatethe shared secret is the same process used by access device 102 at step304 of FIG. 3.

At step 406, a session key is generated using the shared secretgenerated at step 405. The session key may be of any suitable format(e.g., AES, DES, Blowfish, etc.), of any suitable length, and generatedusing any suitable key derivation function. For example, in oneembodiment, the session key may be generated using the Password-BasedKey Derivation Function 2 (PBKDF2) algorithm. In some embodiments, otherdata, such as an access device identifier, may be used as additionalinputs to the key derivation function. Typically, the algorithm used togenerate the shared secret is the same protocol used by access device102 at step 304 of FIG. 3. Typically, the method used to derive thesession key is the same process used by access device 102 at step 305 ofFIG. 3.

At step 407, user device data is encrypted using the session key togenerate encrypted user device data. Typically, the user device data mayinclude a user device certificate. In some embodiments, user device datamay include other data, such as a user device identifier and/or thecryptographic nonce used to generate the blinded user device public key.

In some embodiments, a second shared secret can used to further userdevice data, such as a user device public key, returned in the response(in addition to the encryption using the first shared secret generatedat step 405). Such embodiments can provide the advantage that the userdevice data does not need to be decrypted when the first shared secretis used. The key can be decrypted when and where the second sharedsecret is established, for instance in a separate device (e.g., ahardware security module (HSM)) remotely connected to the access device102.

At step 408, an authentication response comprising the encrypted userdevice data and the blinded user device public key is sent.

Similarly to the method of FIG. 3, it should be noted that although themethod of FIG. 4 is described with reference to an ephemeral public key(typically received from access device 102), embodiments are not limitedto the use of ephemeral keys. For example, in some embodiments, accessdevice 102 may maintain a persistent key pair (i.e., an “access devicepublic/private key pair”), and use the access device public and privatekeys in place of the ephemeral public and private keys, respectively.

III. Authenticated Communication Flows

A. Deriving a Shared Secret

FIG. 5 shows a data flow diagram illustrating operations performed inestablishing a shared secret between access device 102 and portable userdevice 101 in accordance with some embodiments of the invention.

As shown in FIG. 5, access device 102 uses a public/private key pairgenerator (“KeyGen”) to generate an ephemeral public key (“ePubA”) andan ephemeral private key (“ePrivA”). Access device 101 sends theephemeral public key (“ePubT”) to portable user device 101 in a requestmessage. Portable user device 101 generates a cryptographic nonce(“NonceC”), and combines (“MUL”) the cryptographic nonce (“NonceU”) witha user device private key (“PrivU”) to generate a blinded user deviceprivate key (“PrivU*”). The blinded user device private key (“PrivC*”)and an ephemeral public key (“ePubT”) are then used as inputs to anelliptic curve Diffie-Hellman (“ECDH”) function to generate a sharedsecret (“Z”).

Portable user device 101 also combines (“MUL”) the cryptographic nonce(“NonceU”) with a user device public key (“PubU”) to generate a blindeduser device public key (“PubU*”). The blinded user device public key(“PubU*”) is transmitted to access device 102 in a response message.Access device 102 uses the blinded user device public key (“PubU*”) andthe ephemeral private key (“ePrivA”) as inputs to the elliptic curveDiffie-Hellman (“ECDH”) function to generate the same shared secret(“Z”).

In this manner, embodiments can establish a shared secret between accessdevice 102 and portable user device 101.

B. Authenticating a User Device

FIG. 6 shows a data flow diagram illustrating operations performed insecurely authenticating a user device 101 to an access device 102according to some embodiments.

As shown in FIG. 6, access device 102 uses a public/private key pairgenerator (“KeyGen”) to generate an ephemeral public key (“ePubA”) andan ephemeral private key (“ePrivA”). Access device 101 sends theephemeral public key (“ePubT”) to portable user device 101 in a requestmessage. Portable user device 101 generates a cryptographic nonce(“NonceC”), and combines (“MUL”) the cryptographic nonce (“NonceU”) witha user device private key (“PrivU”) to generate a blinded user deviceprivate key (“PrivU*”). The blinded user device private key (“PrivC*”)and an ephemeral public key (“ePubT”) are then used as inputs to anelliptic curve Diffie-Hellman (“ECDH”) function to generate a sharedsecret (“Z”).

Portable user device 101 uses shared secret (“Z”) as an input to a keyderivation function (“KDF”) to generate a session key (“SK”). Anauthenticated encryption cipher (“AE”) encrypts a user devicecertificate (“CertU”) and the cryptographic nonce (“NonceU”) using thesession key (“SK”) to generate an encrypted user device certificate(“CertU^(e)”) and an encrypted cryptographic nonce (“NonceU^(e)”).Portable user device 101 also combines (“MUL”) the cryptographic nonce(“NonceU”) with a user device public key (“PubU”) to generate a blindeduser device public key (“PubU*”). The blinded user device public key(“PubU*”), the encrypted user device certificate (“CertU^(e)”), and theencrypted cryptographic nonce (“NonceU^(e)”) are then transmitted toaccess device 102 in a response message.

Access device 102 uses the blinded user device public key (“PubU*”) andthe ephemeral private key (“ePrivA”) as inputs to the elliptic curveDiffie-Hellman (“ECDH”) function to generate the same shared secret(“Z”). The shared secret (“Z”) is used as an input to the key derivationfunction (“KDF”) to generate the same session key (“SK”). Anauthenticated decryption function (“AE⁻¹”) decrypts the cryptographicnonce (“NonceU”), the user device certificate (“CertU”), and a userdevice public key (“PubU”) included in the user device certificate(“CertU”). An elliptic curve digital signature algorithm (“ECDSA”) isused to verify the user device certificate (“CertU”) using thecertificate authority's public key (“PubCA”). The received blinded userdevice public key (“PubU*) is verified by comparing it to a blinded userdevice public key (“PubU*₂”) generated from the decrypted user devicepublic key (“PubU”) and the decrypted cryptographic nonce (“NonceU”).

If both the user device certificate and the blinded user device publickey are verified, user device 101 is authenticated.

IV. Optimized Authenticated Communication Methods

FIGS. 7 and 8, and Tables 1 and 2 describe optimized methods for securecommunication in accordance with some embodiments of the invention.Specifically, in some embodiments, a user device 101 and an accessdevice 102 may each maintain a registry of devices with whichcommunication occurred in the past. Each registered device may beassociated with a next shared secret and/or other data to be used infuture communication sessions with the device. In this manner,embodiments can avoid certain operations, such as a Diffie-Hellman keyexchange, in any subsequent communication between two devices. Thus,embodiments can reduce the amount of time and processing needed toestablish communication sessions. In addition, embodiments can achievethese benefits while protecting the identity of the user device 101, aswill be described in further detail below.

A. Access Device

FIG. 7 shows an optimized method 700 of securely obtaining user devicedata. In some embodiments, method 700 may comprise some or all steps ofmethod 300 of FIG. 3. In addition, in some embodiments, method 700 maybe performed in conjunction with method 800 of FIG. 8, wherein method700 is performed by an access device 102, and method 800 is performed bya user device 101.

Typically, before the method, portable user device 101 may generate orbe loaded with a user device key pair. A “user device key pair” mayinclude a public key (i.e., a “user device public key”) and a privatekey (i.e., a “user device private key”). User device 101 may alsocomprise a “user device certificate” including the user device publickey. The user device certificate may be signed by a certificateauthority, such as payment processing network 105 or issuer computer106.

In addition, both user device 101 and access device 102 may maintain aregistry of devices with which prior communication has occurred. A“registry” may include any suitable electronic medium for the storage ofdata. For example, a registry may comprise a database, a text file, orany other suitable medium.

At step 701, an ephemeral key pair is generated. An “ephemeral key pair”may include a public key (i.e., an “ephemeral public key”) and a privatekey (i.e., an “ephemeral private key) generated for use with a singletransaction or other communication session. The ephemeral key pair maybe of any suitable format, such as ECC or RSA. Typically, the ephemeralkey pair may be deleted once a communication session between the accessdevice 102 and the portable user device 101 has ended.

At step 702, an authentication request is sent to portable user device101 including the ephemeral public key and an access device identifierassociated with access device 102. An “access device identifier” mayinclude any data suitable to identify an access device. In someembodiments, the authentication request may be sent when access device102 detects a portable user device 101, such as if it passes close to acontactless transceiver.

At step 703, encrypted user device data, a blinded user device publickey, and a blinded user device identifier are received from portableuser device 101. The “encrypted user device data” may include any dataor information associated with a user device. For example, in someembodiments, the encrypted user device data may include an encrypteduser device certificate and the cryptographic nonce used to generate theblinded user device public key. The “blinded user device public key” maybe generated from a user device public key. For example, the blindeduser device public key may be a combination of the user device publickey and a cryptographic nonce. The “blinded user device identifier” maybe generated from a user device identifier for user device 101. In someembodiments, the user device identifier may be a user device public key.In some such embodiments, the blinded user device identifier may be atruncated version of the blinded user device public key. In otherembodiments, the user device identifier may be a serial number, globallyunique identifier (GUID), or other data. In some such embodiments, theuser device identifier may be a combination of the user deviceidentifier and a cryptographic nonce.

At step 704, it is determined if the blinded user device identifier isregistered. For example, in some embodiments, a registry may be searchedfor the blinded user device identifier.

If the blinded user device identifier is registered, at step 705, ashared secret associated with the blinded user device identifier isobtained. For example, in some embodiments, the shared secret may beretrieved from a record in the registry associated with the blinded userdevice identifier. The method then proceeds to step 707.

If the blinded user device identifier is not registered, at step 706,step 304 of FIG. 3 is performed. Specifically, a shared secret isgenerated using the ephemeral private key generated at step 701 and theblinded user device public key received at step 703. The shared secretmay be generated using any suitable method. For example, in embodimentsusing elliptic curve cryptography, the shared secret may be determinedusing the elliptic-curve Diffie-Hellman protocol (ECDH). The method thenproceeds to step 707.

At step 707 of method 700, steps 305-308 of method 300 are performed.Specifically, in some embodiments, the shared secret is used to generatea session key. The session key is used to decrypt the encrypted userdevice data to determine a user device certificate. The user devicecertificate and the blinded user device public key are then validated. Atransaction is then conducted using the decrypted user device data.Further description of these steps may be found with reference to thecorresponding steps in FIG. 3.

At step 708, a next shared secret and a next blinded user deviceidentifier are generated using the shared secret. The next shared secretand the next blinded user device identifier may be generated from theshared secret in any suitable manner. For example, in some embodiments,the next shared secret may be determined using a key derivationfunction. For instance, the key derivation function used to generate thesession key at step 707 may also generate the next shared secret.

The next blinded user device identifier may also be generated using akey derivation function. For example, in some embodiments, the keyderivation function used to generate the session key at step 707 may beused to generate a next cryptographic nonce. The next cryptographicnonce and the user device public key may then be used to generate a nextblinded user device public key. In some embodiments, the next blindeduser device identifier may be a subset of the next blinded user devicepublic key. In other embodiments, the cryptographic nonce may becombined with the blinded user device identifier to determine the nextblinded user device identifier. Typically, the process used to determinethe next blinded user device identifier at step 708 is also used by userdevice 101 at step 807 of method 800.

At step 709, the next blinded user device identifier is registered andassociated with the next shared secret. For example, in someembodiments, the next blinded user device identifier and the next sharedsecret may be stored in a registry or database.

B. User Device

FIG. 8 shows an optimized method of securely transmitting user devicedata to an access device. Typically, before the method, portable userdevice 101 may generate or be loaded with a user device key pair. A“user device key pair” may include a public key (i.e., a “user devicepublic key”) and a private key (i.e., a “user device private key”). Userdevice 101 may also comprise a “user device certificate” including theuser device public key. The user device certificate may be signed by acertificate authority, such as payment processing network 105 or issuercomputer 106.

In addition, both user device 101 and access device 102 may maintain aregistry of devices with which prior communication has occurred. A“registry” may include any suitable electronic medium for the storage ofdata. For example, a registry may comprise a database, a text file, orany other suitable medium.

At step 801, an authentication request from access device 102 isreceived comprising an ephemeral public key and an access deviceidentifier. The ephemeral public key may be of any suitable format, suchas ECC or RSA. Typically, the ephemeral public key may be deleted onceit has been used (e.g., after a communication session between the accessdevice 102 and the portable user device 101 has ended). An “accessdevice identifier” may include any data suitable to identify an accessdevice.

At step 802, it is determined if the access device identifier isregistered. For example, in some embodiments, a registry may be searchedfor the access device identifier.

If the access device identifier is registered, at step 803, a sharedsecret, a blinded user device public key, and a blinded user deviceidentifier associated with the access device identifier are obtained.For example, in some embodiments, the shared secret, the blinded userdevice public key, and the blinded user device identifier may beretrieved from a record in the registry associated with the blinded userdevice identifier. In some embodiments, some or all of the sharedsecret, the blinded user device public key, and the blinded user deviceidentifier may overlap. For instance, the blinded user device identifiermay be a subset (e.g., the last 4 or 8 bits) of the blinded user devicepublic key. Method 800 then proceeds to step 805.

If the access device is not registered, at step 803, steps 402-405 ofmethod 400 are performed. Specifically, in some embodiments, acryptographic nonce is generated. A blinded user device private key isgenerated using the cryptographic nonce and the user device private key,and a blinded user device public key is generated using the nonce andthe user device public key. A shared secret is then generated using theblinded user device private key and the ephemeral public key received atstep 801. Further description of these steps may be found with referenceto the corresponding steps in FIG. 4. Method 800 then proceeds to step805.

At step 805, steps 406-408 of method 400 are performed. Specifically, insome embodiments, a session key is generated using the shared secret.The session key is used to encrypt user device data, such as a userdevice certificate. An authentication response message is then sent toaccess device 102, the response including the encrypted user device dataand the blinded user device public key. Further description of thesesteps may also be found with reference to the corresponding steps inFIG. 4.

At step 806, a next shared secret, a next blinded user deviceidentifier, and a next blinded user device public key are generatedusing the shared secret. The next shared secret, the next blinded userdevice identifier, and the next blinded user device public key may begenerated from the shared secret in any suitable manner. For example, insome embodiments, the next shared secret may be determined using a keyderivation function. For instance, the key derivation function used togenerate the session key at step 805 may also generate the next sharedsecret.

The next blinded user device identifier may also be generated using akey derivation function. For example, in some embodiments, the keyderivation function used to generate the session key at step 805 may beused to generate a cryptographic nonce. The cryptographic nonce and theuser device public key may then be used to generate a next blinded userdevice public key. In some embodiments, the next blinded user deviceidentifier may be a subset of the next blinded user device public key.In other embodiments, the cryptographic nonce may be combined with theblinded user device identifier to determine the next blinded user deviceidentifier. Typically, the process used to determine the next blindeduser device identifier at step 806 is also used by access device 102 atstep 708 of method 700.

At step 807, the next blinded user device identifier is registered andassociated with the next shared secret. For example, in someembodiments, the next blinded user device public key and the next sharedsecret may be stored in a registry or database.

C. Pseudo-Code Listing

Tables 1 and 2 below show pseudocode listings to implement a securemethod for authenticated data transmission in accordance with someembodiments of the invention.

TABLE 1 Line Pseudo-code A1 GenKeyPair(d_(eA); Q_(eA)) A2SendAuthenticationRequest(ID_(sA) || Q_(eA) || CB_(A)) wait forresponse: BData_(U) || EncData_(U) A3 ID_(sU) = (T₈(BData_(U))) A4 CheckBData_(U) belongs to EC domain A5 If ID_(sU) not registered: A6 Z =EC_DH (d_(eA); BData_(U)) A7 Zeroize d_(eA) A8 Else: A9 Obtain Z fromID_(sU) in PB registry A10 SK_(CFRM) || SK_(MAC) || SK_(ENC) ||SK_(RMAC) || NextZ || NextBlind = KDF (Z, len, info (ID_(sU), ID_(sA),T₁₆(Q_(eA))) A11 Zeroize Z A12 Header || C_(U) || N_(U) || CB_(U) = AE⁻¹(SK_(CFRM); EncData_(U)) A13 Verify Header == “KC_1_V” A14 If (CB_(U) &PB_INIT): A15 NextID_(sU) = T₈(NextBlind . Q_(sU)) A16 Register Z=NextZin new entry for ID_(sU) = NextID_(sU) (place [ID_(sU), Z] entry inunused or least used location of PB registry) A17 If ( (CB_(U) & PB_INIT) or (CB_(U) & NO_PB) ): A18 Verify C_(U) signature with ECDSA A19 GetQ_(sU) from C_(U) A20 Verify BData_(U) = T₄(N_(U)) . Q_(sU) A21(Optional: Conduct additional secure messaging using SK_(MAC),SK_(RMAC), and SK_(ENC))

Table 1 shows a pseudocode listing to implement a method of securelyobtaining user device data from a user device. As described below, themethod of Table 1 is performed by an access device 102 communicatingwith a user device 101. However, in other embodiments, the method may beperformed by any other suitable entity.

At step A1, an ephemeral key pair is generated. The ephemeral key pairincludes an ephemeral private key (d_(eA)) and an ephemeral public key(Q_(eA)).

At step A2, an authentication request is sent to user device 101including an access device identifier (ID_(sA)), the ephemeral publickey (Q_(eA)), and an access device protocol control byte (CB_(A)) thatindicates various information regarding access device 102.

After the authentication request is sent, a wait occurs until anauthentication response is received from user device 101. Theauthentication response includes a blinded user device public key(BData_(U)) and encrypted user device data (EncData_(U)).

At step A3, a blinded user device identifier (ID_(sU)) is determined bytaking the leftmost 8 bytes (T₈) of the blinded user device public key(BData_(U)).

At step A4, a check is performed to ensure that the blinded user devicepublic key (BData_(U)) belongs to an expected elliptic curve (EC)domain.

At step A5, a check is performed to determine whether the blinded userdevice identifier (ID_(sU)) was previously registered by access device102. If the blinded user device identifier (ID_(sU)) is not registered,then at step A6 a shared secret (Z) is computed by combining theephemeral private key (d_(eA)) and the received blinded user devicepublic key (Bdata_(U)). Once the shared secret is computed, at step A7the ephemeral private key is erased.

At step A8, if the blinded user device identifier (ID_(sU)) isregistered, then at step A9, a shared secret (Z) is obtained from apersistent binding (PB) registry using the blinded user deviceidentifier (ID_(sU)).

At step A10, several session keys (SK_(CFRM), SK_(MAC), SK_(ENC), andSK_(RMAC)), a next shared secret (NextZ), and a next cryptographic nonce(NextBlind) are derived using a key derivation function (KDF). Theinputs to the key derivation function are the shared secret (Z), adesired output length (len), and a combination of the blinded userdevice identifier (ID_(sU)), the access device identifier (ID_(sA)), andthe left 16 bytes of the ephemeral public key (Q_(eA)). Once the keyderivation function is completed, at step A11, the shared secret iserased.

At step A12, a derived session key (SK_(CFRM)) is used to decrypt theencrypted user device data (EncData_(U)) using an authenticateddecryption algorithm (AE⁻¹). A header (Header), a user devicecertificate (C_(U)), a cryptographic nonce (N_(U)), and a user deviceprotocol control byte (CB_(U)) are determined from the decrypted userdevice data.

At step A13, the header is compared to an expected value. In someembodiments, if the header does not match the expected value,authentication of user device 101 may fail.

At step A14, the user device protocol control byte (CB_(U)) is inspectedto determine whether user device 101 intends to compute and register anew shared secret. If so, then at step A15, a next blinded user deviceidentifier (NextID_(sU)) is determined using the next cryptographicnonce (NextBind) and the user device public key (Q_(sU)). At step A16,the next shared secret (NextZ) and the next blinded user deviceidentifier (NextID_(sU)) are registered.

At step A17, the user device protocol control byte (CB_(U)) is inspectedto determine whether user device 101 intends to compute and register anew shared secret or if user device 101 does not support persistentbinding. If either is the case, then at step A18, the user devicecertificate (C_(U)) is verified using an elliptic curve digitalsignature algorithm (ECDSA). In addition, at step A19, the user devicepublic key is determined from the user device certificate (C_(U)). Theuser device public key (Q_(sU)) is combined with the left four bytes ofthe nonce (N_(U)) to verify that the received blinded user device publickey is consistent with the user device certificate. If both thecertificate and the blinded user device public key are verified, userdevice 101 may be authenticated.

At step A21, further communication may be conducted using one or more ofthe derived session keys.

TABLE 2 Line Pseudo-code Receive authentication request: ID_(sA) ||Q_(eA) || CB_(A) U1 CB_(U) = CB_(A) & ‘F0’ U2 Generate Nonce N_(U) U3Look for ID_(sA) in PB registry U4 If (ID_(sA) is not registered) or((CB_(A) & ‘0F’) != PB) : U5 Validate Q_(eA) belongs to EC domain U6 Z =EC_DH(N_(U) . d_(sU); Q_(eA)) U7 BData_(U) = T₄(N_(U)) . Q_(sU) U8 Else:U9 Retrieve Z, BData_(U) from PB registry using ID_(sA) U10 CB_(U) |= PBU11 ID_(sU) = T₈(BData_(U)) U12 SK_(CFRM) || SK_(MAC) || SK_(ENC) ||SK_(RMAC) || NextZ || NextBlind = KDF (Z, len, info (ID_(sU), ID_(sA),T₁₆(Q_(eA))) U13 Zeroize Z U14 EncData_(U) = AE (SK_(CFRM), “KC_1_V” ||C_(U) || N_(U) || CB_(U)) U15 If user device supports PB AND (CB_(A) &NO_PB)==0 AND (ID_(sA) is not registered or (CB_(A) & PB_INIT)): U16Register Z = NextZ, NextBData_(U) = T₄(NextBlind) . Q_(sU) in new entryfor ID_(sA) U17 CB_(U) |= PB_INIT U18 Else if CB_(U) != PB: U19 CB_(U)|= NO_PB U20 Return BData_(U) || EncData_(U)

Table 2 shows a pseudocode listing to implement a method of securelytransmitting user device data to an access device. As described below,the method of Table 2 is performed by a user device 101 communicatingwith an access device 102. However, in other embodiments, the method maybe performed by any other suitable entity.

Prior to the method of Table 2, an authentication request message may bereceived from access device 102. The authentication request may includean access device identifier (ID_(sA)), the ephemeral public key(Q_(eA)), and an access device protocol control byte (CB_(A)) thatindicates various information regarding access device 102.

At step U1, a user device protocol control byte (CB_(U)) is preparedusing the received access device protocol control byte (CB_(A)).

At step U2, a cryptographic nonce (N_(U)) is generated.

At step U3, the received access device identifier (ID_(sA)) is looked upin a registry at user device 101.

At step U4, if the access device identifier (ID_(sA)) is not registered,or if the access device protocol control byte (CB_(A)) indicates thatpersistent binding is not supported by access device 101, steps U5-U7are performed. At step U5, a check is performed to ensure that theephemeral public key (Q_(eA)) belongs to the correct elliptic curve (EC)domain. At step U6, a shared secret (Z)) is computed by combining theephemeral public key (Q_(eA)) and a user device private key (d_(sU))that has been blinded by the nonce (N_(U)). In addition, at step U7, ablinded user device public key (BData_(U)) is generated using a userdevice public key (Q_(sU)) and the left four bytes of the nonce(T₄(N_(U))).

At step U8, if the condition checked at step U4 is not true, then stepsU9 and U10 are performed. At step U9, a shared secret (Z) and a blindeduser device public key (BData_(U)) are retrieved from a registry usingthe access device identifier (ID_(sA)). At step U10, the user deviceprotocol control byte is updated to indicate that persistent binding issupported.

At step U11, a blinded user device identifier (ID_(sU)) is determined bytaking the leftmost 8 bytes of the blinded user device public key(BData_(U)).

At step U12, several session keys (SK_(CFRM), SK_(MAC), SK_(ENC), andSK_(RMAC)), a next shared secret (NextZ), and a next cryptographic nonce(NextBlind) are derived using a key derivation function (KDF). Theinputs to the key derivation function are the shared secret (Z), adesired output length (len), and a combination of the blinded userdevice identifier (ID_(sU)), the access device identifier (ID_(sA)), andthe left 16 bytes of the ephemeral public key (Q_(eA)). Once the keyderivation function is completed, at step U13, the shared secret iserased.

At step U14, an authenticated encryption function (AE) is used toencrypt a predefined header (“KC_1_V”), a user device certificate(C_(U)), the cryptographic nonce (N_(U)), and the user protocol controlbyte (CB_(U)). The result of the encryption function is encrypted userdevice data (EncData_(U)).

At step U15, if user device 101 and access device 102 support persistentbinding (as indicated by their respective protocol control bytes), andeither the access device identifier (ID_(sA)) is not registered or are-registration is requested (as indicated by the access controlprotocol control byte), steps U16-U17 are performed. At step U16, thenext shared secret (NextZ), and the next blinded user device public key(NextBData_(U)) are registered and associated with the access deviceidentifier (ID_(sA)). At step U17, the user device protocol control byte(CB_(U)) is updated to indicate that user device 101 has computed a newnext shared secret associated with access device 102.

At step U18, if the conditional at step U15 is not true and user device101 does not support persistent binding, then at step U19, the userdevice protocol control byte (CB_(U)) is updated to indicate thatpersistent binding is not supported.

At step U20, an authentication response message is sent to access device102 including the blinded user device public key (BData_(U)) and theencrypted user device data (EncData_(U)).

V. Aparatuses

FIG. 9 shows an example of a payment device 101″ in the form of a card.As shown, the payment device 101″ comprises a plastic substrate 101(m).In some embodiments, a contactless element 101(o) for interfacing withan access device 102 may be present on, or embedded within, the plasticsubstrate 101(m). User information 101(p) such as an account number,expiration date, and/or a user name may be printed or embossed on thecard. A magnetic stripe 101(n) may also be on the plastic substrate101(m). In some embodiments, the payment device 101″ may comprise amicroprocessor and/or memory chips with user data stored in them.

As noted above and shown in FIG. 9, the payment device 101″ may includeboth a magnetic stripe 101(n) and a contactless element 101(o). In someembodiments, both the magnetic stripe 101(n) and the contactless element101(o) may be in the payment device 101″. In some embodiments, eitherthe magnetic stripe 101(n) or the contactless element 101(o) may bepresent in the payment device 101″.

FIG. 10 is a high level block diagram of a computer system that may beused to implement any of the entities or components described above. Thesubsystems shown in FIG. 10 are interconnected via a system bus 1075.Additional subsystems include a printer 1003, keyboard 1006, fixed disk1007, and monitor 1009, which is coupled to display adapter 1004.Peripherals and input/output (I/O) devices, which couple to I/Ocontroller 1000, can be connected to the computer system by any numberof means known in the art, such as a serial port. For example, serialport 1005 or external interface 1008 can be used to connect the computerapparatus to a wide area network such as the Internet, a mouse inputdevice, or a scanner. The interconnection via system bus 1075 allows thecentral processor 1002 to communicate with each subsystem and to controlthe execution of instructions from system memory 1001 or the fixed disk1007, as well as the exchange of information between subsystems. Thesystem memory 1001 and/or the fixed disk may embody a computer-readablemedium.

As described, the inventive service may involve implementing one or morefunctions, processes, operations or method steps. In some embodiments,the functions, processes, operations or method steps may be implementedas a result of the execution of a set of instructions or software codeby a suitably-programmed computing device, microprocessor, dataprocessor, or the like. The set of instructions or software code may bestored in a memory or other form of data storage element which isaccessed by the computing device, microprocessor, etc. In otherembodiments, the functions, processes, operations or method steps may beimplemented by firmware or a dedicated processor, integrated circuit,etc.

It should be understood that the present invention as described abovecan be implemented in the form of control logic using computer softwarein a modular or integrated manner. Based on the disclosure and teachingsprovided herein, a person of ordinary skill in the art will know andappreciate other ways and/or methods to implement the present inventionusing hardware and a combination of hardware and software.

Any of the software components or functions described in thisapplication may be implemented as software code to be executed by aprocessor using any suitable computer language such as, for example,Java, C++ or Perl using, for example, conventional or object-orientedtechniques. The software code may be stored as a series of instructions,or commands on a computer-readable medium, such as a random accessmemory (RAM), a read-only memory (ROM), a magnetic medium such as ahard-drive or a floppy disk, or an optical medium such as a CD-ROM. Anysuch computer-readable medium may reside on or within a singlecomputational apparatus, and may be present on or within differentcomputational apparatuses within a system or network.

While certain exemplary embodiments have been described in detail andshown in the accompanying drawings, it is to be understood that suchembodiments are merely illustrative of and not intended to berestrictive of the broad invention, and that this invention is not to belimited to the specific arrangements and constructions shown anddescribed, since various other modifications may occur to those withordinary skill in the art.

As used herein, the use of “a”, “an” or “the” is intended to mean “atleast one”, unless specifically indicated to the contrary.

What is claimed is:
 1. An access device comprising: a processor; and anon-transitory computer-readable storage medium comprising codeexecutable by the processor for implementing a method comprising:sending an access device public key to a user device, wherein the accessdevice public key is associated with an access device private key;receiving a blinded user device public key and encrypted user devicedata from the user device, wherein the blinded user device public key isgenerated using a user device public key and a cryptographic nonce; andgenerating a shared secret using the access device private key and theblinded user device public key; and decrypting the encrypted user devicedata using the shared secret.
 2. The access device of claim 1, whereinthe access device key pair is an ephemeral key pair, wherein theephemeral key pair is deleted after the shared secret is determined. 3.The access device of claim 1, wherein decrypting the encrypted userdevice data using the shared secret comprises generating a session keyusing the shared secret.
 4. The access device of claim 1, wherein theuser device data comprises a user device certificate comprising a userdevice public key and the cryptographic nonce used to generate theblinded user device public key, and wherein the method furthercomprises: validating the user device certificate; generating a secondblinded user device public key using the user device public key and thecryptographic nonce; and comparing the second blinded user device publickey with the received blinded user device public key, wherein the userdevice is authenticated if the second blinded user device public keymatches the received blinded user device public key.
 5. The accessdevice of claim 1, wherein the shared secret is a first shared secret,and wherein the method further comprises: generating a second sharedsecret using the first shared secret; and associating the second sharedsecret with the user device, wherein the second shared secret is used todecrypt subsequent user device data received from the user device. 6.The access device of claim 1, the method further comprising: conductinga transaction using the user device data.
 7. A system comprising: theaccess device of claim 1; and the user device, wherein the user deviceis configured to: receive an access device public key; generate a sharedsecret using the access device public key, a user device private key,and the cryptographic nonce; encrypt user device data using the sharedsecret; and send the encrypted user device data and the blinded userdevice public key to the access device.
 8. A computer-implemented methodcomprising: sending, by an access device having one or more processors,an access device public key to a user device, wherein the access devicepublic key is associated with an access device private key; receiving,by the access device, a blinded user device public key from the userdevice, wherein the blinded user device public key is generated using auser device public key and a cryptographic nonce; and generating, by theaccess device, a shared secret using the access device private key andthe blinded user device public key, wherein the shared secret is knownto the user device.
 9. The computer-implemented method of claim 8,wherein the access device key pair is an ephemeral key pair, wherein theephemeral key pair is deleted after shared secret is generated.
 10. Thecomputer-implemented method of claim 8, further comprising: generating,by the access device, a session key using the shared secret, wherein thesession key is used to .
 11. The computer-implemented method of claim10, further comprising: receiving, by the access device, encrypted userdevice data from the user device; and decrypting, by the access device,the encrypted user device data using the session key to determine userdevice data.
 12. The computer-implemented method of claim 11, whereinthe user device data comprises a user device certificate comprising auser device public key and a cryptographic nonce used to generate theblinded user device public key, and wherein the method furthercomprises: validating, by the access device, the user devicecertificate; generating, by the access device, a second blinded userdevice public key using the user device public key and the cryptographicnonce; and comparing, by the access device, the second blinded userdevice public key with the received blinded user device public key,wherein the user device is authenticated if the second blinded userdevice public key matches the received blinded user device public key.13. The computer-implemented method of claim 11, wherein the sharedsecret is a first shared secret, and wherein the method furthercomprises: generating, by the access device, a second shared secretusing the first shared secret; and associating, by the access device,the second shared secret with the user device, wherein the second sharedsecret is used to decrypt subsequent user device data received from theuser device.
 14. The computer-implemented method of claim 11, furthercomprising: conducting, by the access device, a transaction using theuser device data.
 15. A computer-implemented method comprising:receiving, by a user device, an access device public key from an accessdevice; generating, by the user device, a shared secret using the accessdevice public key and a user device private key; generating, by the userdevice, a blinded user device public key using a user device public keyand a cryptographic nonce; encrypting, by the user device, user devicedata using the shared secret; and sending, by the user device, theblinded user device public key and the encrypted user device data to theaccess device, thereby allowing the access device to generate the sharedsecret using the blinded user device public key and an access deviceprivate key corresponding to the access device public key and to decryptthe encrypted user device data using the shared secret.
 16. Thecomputer-implemented method of claim 15, wherein the access device keypair is an ephemeral key pair, wherein the user device deletes theaccess device public key after the shared secret is generated.
 17. Thecomputer-implemented method of claim 15, wherein encrypting the userdevice data comprises generating, by the user device, a session keyusing the shared secret.
 18. The computer-implemented method of claim17, further comprising: encrypting, by the user device, user device datausing the session key to generate encrypted user device data; andsending, by the user device, the encrypted user device data to theaccess device.
 19. The computer-implemented method of claim 18, whereinthe user device data comprises a user device certificate and acryptographic nonce used to generate the blinded user device public key,and wherein the access device authenticates the user device using theuser device certificate and the cryptographic nonce.
 20. Thecomputer-implemented method of claim 18, wherein the shared secret is afirst shared secret, and wherein the method further comprises:generating, by the user device, a second shared secret using the firstshared secret; and associating, by the user device, the second sharedsecret with the access device, wherein the second shared secret is usedto encrypt subsequent user device data sent by the user device.
 21. Thecomputer-implemented method of claim 18, wherein the access deviceconducts a transaction using the user device data.